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Abstract 


Implicit  invocation  [SN92,GN91]  has  become  an  important  architectural  style  for  large- 
scale  system  design  and  evolution.  This  paper  addresses  the  lack  of  specification  and 
verification  formalisms  for  such  systems.  A  formal  computational  model  for  implicit 
invocation  is  presented.  We  develop  a  verification  framework  for  implicit  invocation 
that  is  based  on  Jones'  rely /guarantee  reasoning  for  concurrent  systems  [Jon835St091]. 
The  application  of  the /ramework  is  illustrated  with  several  examples.  The  merits  and 
limitations  of  the  rely /guarantee  paradigm  in  the  context  of  implicit  invocation  systems 
are  also  discussed. 
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Introduction 


A  critical  issue  for  large-scale  systems  design  and  evolution  is  the  choice  of  an 
architectural  style  that  permits  the  integration  of  separately-developed  compo¬ 
nents  into  larger  systems.  Familiar  styles  include  those  based  on  remote  proce¬ 
dure  call  [BN84],  shared  variables,  asynchronous  message  passing,  etc. 

One  key  factor  determining  the  effectiveness  of  an  architectural  style  is  the 
ability  to  reason  effectively  about  properties  of  a  system  from  properties  of  its 
components.  As  a  result,  considerable  effort  has  gone  into  techniques  for  compo¬ 
sition  based  on  procedure  invocation  [Dij76,Hoa69],  shared  data  [CM88,OG76], 
and  message  passing  [Hoa85,Mil80,ISO87].  Even  though  practitioners  rarely  carry 
out  formal  reasoning  throughout  the  full  design  and  implementation  process, 
they  can  both  use  the  techniques  as  needed  and  also  apply  intuition  that  has 
been  built  up  during  development  of  the  supporting  techniques. 

One  increasingly  important  architectural  style  for  system  composition  is  im¬ 
plicit  invocation  (II)  [SN92,GN91]h  At  its  heart,  II  is  based  on  the  idea  that 
a  component  A  can  invoke  another  component  B  without  A  being  required  to 
know  B’s  name.  Components  such  as  B  “register”  interest  in  particular  “events” 
that  components  such  as  A  “announce.”  When  A  announces  such  an  event,  the 
II  mechanism  is  responsible  for  invoking  component  B,  even  though  A  doesn’t 
know  that  B  or  any  other  components  are  registered.^ 

There  are  a  number  of  benefits  of  using  the  II  architectural  style,  and  it  has 
been  used  in  diverse  settings  such  as  programming  environments  and  operating 
systems  and  others.  Mechanisms  to  support  II  are  found  in  commercial  toolkits 
(e.g.,  Softbench  [Ger89],  ToolTalk,  DecFuse),  communication  standards  (e.g., 
Corba),  integration  frameworks  (e.g.,  OLE),  and  programming  environments 
(e.g.,  Smalltalk). 

However,  there  is  currently  no  established  basis  for  reasoning  about  II  sys¬ 
tems.  In  particular  it  is  difficult  to  answer  questions  like:  What  will  be  the  ef¬ 
fect  of  announcing  a  given  event?  Have  enough  event  bindings  been  declared  to 
achieve  desired  system  behaviour?  Does  a  given  component  announce  sufficient 
events  to  permit  effective  integration?  If  a  new  component  is  added  to  an  exist¬ 
ing  system,  will  it  break  the  existing  system?  Are  there  the  right  components  to 
produce  desired  overall  system  behaviour? 

•  In  this  paper  we  describe  one  approach  to  providing  such  a  basis  for  rea¬ 
soning  about  systems  designed  using  the  H  architectural  style.  The  basic  ideas 
are  based  on  extending  Jones’  rely /guarantee  approach  to  events.  Specifically, 
we  augment  the  assertion  language  to  allow  us  to  express  the  conditions  under 
which  a  component  will  announce  events.  The  overall  system  behaviour  can  then 
be  reasoned  about  by  establishing  invariants  over  the  effects  achieved  by  individ¬ 
ual  components  together  with  the  state  of  pending  events  (i.e.,  those  waiting  to 
implicitly-invoke  other  computations).  In  order  to  reason  with  these  invariants 

^  In  other  contexts  “implicit  invocation”  is  referred  to  by  other  names,  such  as 
“publish-sub scribe”  and  “event  multicast”. 

^  In  this  paper,  as  we  will  see,  a  “component”  is  just  a  procedure  or  method. 
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we  are  also  led  to  impose  several  constraints  on  the  form  of  system  computa¬ 
tions  to  guarantee  the  atomicity  of  certain  state  changes.  As  we  will  discuss,  the 
need  for  these  additional  constraints  illustrates  some  of  the  limitations  of  an  ap¬ 
proach  based  on  rely /guarantee,  and  suggests  future  extensions  of  the  techniques 
described  in  the  paper. 


1.1  II  Systems:  utility  and  challenges 

As  sketched  above,  the  central  notion  underlying  II  systems  is  that  the  “invokes” 
relation  is  decoupled  from  the  “names”  (or  “knows-about”)  relation.  That  is,  a 
component  A  can  invoke  a  component  B  without  knowing  B’s  name.  One  of  the 
simplest  examples  of  II  is  when  an  operating  system  allows  user  code  to  register 
a  callback  procedure.  For  example,  user  code  might  register  a  procedure  that 
is  invoked  when  a  particular  signal  is  raised  by  the  kernel.  This  allows  the  user 
code  added  control  without  compromising  the  kernel. 

A  somewhat  more  complicated  example  arises  in  broadcast  message-based 
programming  environments  (such  as  those  derived  from  Reiss’  Field  [ReiQO]  sys¬ 
tem).  A  collection  of  tools,  such  as  a  compiler,  a  debugger,  an  editor,  a  pro¬ 
gram  visualization  tool,  etc.,  execute  together.  Rather  than  calling  one  another 
directly,  at  appropriate  times  they  each  announce  potentially  interesting  activi¬ 
ties.  For  example,  the  editor  might  announce,  “procedure  f  was  saved”,  while  the 
debugger  might  announce,  “the  breakpoint  in  file  x.c  at  line  173  was  reached.” 
Other  tools  might  decide  to  listen  for  particular  kinds  of  announcements.  For 
example,  the  editor  might  listen  for  “breakpoint”  announcements,  so  that  it  can 
move  the  cursor  to  the  appropriate  file  and  line.  A  centralized  message  server  is 
used  to  deliver  announcements  to  the  tools  that  have  registered  interest. 

By  having  tools  announce  potentially  interesting  events,  and  by  having  tools 
register  interest,  the  conventional  link  between  “invokes”  and  “names”  is  bro¬ 
ken.  In  the  example  above,  for  instance,  the  debugger  “invokes”  the  editor  by 
announcing  a  breakpoint  event,  but  the  debugger  is  unaware  of  this.  Indeed, 
some  editors  might  not  listen  for  this  event,  or  multiple  tools  (even  multiple 
editors)  might  listen  for  it.  So,  not  only  is  implicit  invocation  used,  but  the  invo¬ 
cation  relation  becomes  one-to-many  as  opposed  to  the  conventional  one-to-one 
in  conventional  direct  procedure  invocation  approaches.^ 

The  conventional  approach  to  reasoning  about  software  systems  depends  on 
the  link  between  invokes  and  names.  Specifically,  it  is  hierarchical  and  thus 
will  not  apply  directly  to  II  systems.  In  the  hierarchical  approach  there  are  a 
set  of  primitives — often  language  constructs— that  are  associated  with  specific 
semantics  (weakest  preconditions,  for  example).  Then  one  defines  pre-  and  post¬ 
conditions  for  procedures  and  uses  standard  compositional  techniques  over  the 
primitives  to  demonstrate  that  the  axiomatic  conditions  hold.  These  conditions 

^  Logically,  there  is  no  reason  that  conventional  procedure  invocation  need  be  one- 
to-one.  But  it  happens  at  most  rarely,  and  the  one-to-many  is  a  natural  extension 
of  implicit  invocation.  Note,  however,  that  the  operating  system  callback  case  is  a 
situation  in  which  it  is  implicit  but  also  one-to-one. 
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are  in  turn  used  as  primitives  to  prove  properties  about  the  enclosing  procedures. 
And  so  on,  until  one  can  prove  a  property  (often  correctness)  at  the  top-level  of 
the  program. 

If  one  changes  one  of  the  primitives  or  procedures,  a  bounded  amount  of 
reasoning  needs  to  be  reapplied:  basically,  proofs  from  that  point  to  the  root  of 
the  tree  need  to  be  redone. 

At  the  heart  of  these  hierarchical  reasoning  approaches  is  the  notion  that  the 
invocation  relation  is  known  statically.  This  is  what  allows  reasoning  about  a 
procedure  to  be  done  in  terms  of  the  primitives  and  preconditions  of  procedures 
in  which  the  given  procedure  is  written.  This  static  invocation  relationship  is  not 
the  fundamental  composition  structure  used  in  II,  so  this  reasoning  approach  is 
not  necessarily  appropriate  for  II  systems. 

To  see  why,  consider  an  approach  that  attempts  to  reduce  reasoning  about 
II  systems  to  standard  hierarchical  reasoning  using  pre-  and  post-conditions.  In 
the  case  of  a  sequential  II  system  (one  in  which  each  event-triggered  procedure 
is  executed  to  completion),  one  would  be  tempted  to  substitute: 

aniiounce(e) 

with  the  corresponding  procedure  calls  of  the  procedures  bound  to  e.  One  can 
then  apply  standard  pre-post  reasoning  techniques  to  the  system. 

However  there  are  two  fundamental  problems  with  this.  First,  it  violates 
the  intended  goal  of  decoupling  the  reasoning  about  a  given  component  from 
the  system  in  which  its  events  are  bound  to  other  components.  This  is  because 
changing  any  binding  requires  reanalysis  of  the  components  that  announce  the 
events  in  the  changed  bindings.  Second,  the  technique  is  not  tractable.  Since 
the  procedures  bound  to  an  event  can  be  invoked  in  any  order,  it  is  necessary 
to  consider  all  n!  sequences  of  procedure  invocations  where  n  is  the  number  of 
procedures. 

In  fact,  the  loosely  coupled  nature  of  the  components  in  II  systems  cause 
them  to  be  formally  much  more  like  a  concurrent  system  than  a  sequential  one 
(even  when  there  is  a  single  thread  of  control) .  Since  the  procedures  associated 
with  an  event  can  be  invoked  in  any  order  by  the  underlying  II  mechanism, 
there  is  inherent  non-determinism  in  II  systems,  similar  to  that  of  concurrently 
executing  processes.  This  suggests  that  it  should  be  possible  to  apply  techniques 
for  reasoning  about  concurrent  systems  to  II  systems.  In  particular,  it  should 
be  possible  to  enhance  the  interface  specifications  of  II  components  so  that  they 
make  explicit  the  role  that  they  play  in  a  system  and  environmental  conditions 
under  which  they  expect  to  function. 

Thus,  the  central  challenge  in  reasoning  about  II  is  to  find  ways  to  specify 
component  interfaces  and  together  with  tractable  composition  mechanisms  for 
reasoning  about  aggregate  behaviour.  This  theory  would  allow  us  to  determine: 

-  Does  a  given  component  satisfy  its  interface? 

-  Is  a  given  composition  well-formed  (complete  and  consistent)? 

-  Is  the  aggregate  behaviour  of  a  system  as  desired? 
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1.2  Related  Work 


There  are  two  general  areas  of  related  work.  The  first  is  research  on  implicit 
invocation  systems.  Most  of  the  work  on  such  systems  has  centered  around  de¬ 
veloping  practical  mechanisms  for  exploiting  the  paradigm  in  real  systems,  such 
as  programming  environments  like  Field  and  Softbench  [Rei90,Ger89].  Our  work 
is  inspired  by  the  practical  success  of  this  work,  and  hopes  to  make  engineering 
efforts  based  on  it  more  effective  by  providing  more  principled  basis  for  reasoning 
about  II  systems. 

Within  the  general  area  of  II  research  several  researchers  have  attempted  to 
provide  precise  characterizations  of  implicit  invocation  systems.  An  earl}^  sur¬ 
vey  of  applications  of  the  technique  appeared  in  [GKN88]  in  which  the  authors 
illustrated  how  and  why  the  ideas  of  II  systems  are  pervasive  in  software  sys¬ 
tems.  More  recently  [BCTW96]  produced  a  taxonomic  survey  of  II  mechanisms, 
together  with  a  generic  object  model  for  comparison  of  them.  While  this  line  of 
research  has  led  to  improved  understanding  of  the  design  space  for  Il-based  sys¬ 
tems,  unlike  our  work,  it  does  not  attempt  to  provide  a  formal  basis  for  reasoning 
about  them. 

Closer  to  our  line  of  research,  several  researchers  have  attempted  to  provide 
a  formal  characterization  of  certain  aspects  of  II  systems.  Two  of  this  paper’s 
authors  produced  an  early  characterization  of  II  systems  in  Z  [GN91].  More 
recently,  researchers  in  software  architecture  have  looked  at  some  of  the  formal 
properties  of  II  architectural  styles  [AAG95].  This  research  was  primarily  focused 
on  taxonomic  issues,  and  does  not  provide  an  explicit  computational  model  that 
permits  compositional  reasoning  about  the  behaviour  of  such  systems. 

Other  researchers  have  looked  at  formal  issues  of  event-multicast  and  process 
groups  as  a  mechanism  for  achieving  fault  tolerance  through  replication  [BJ89]. 
This  work  differs  from  that  on  implicit  invocation  in  that  multiple  recipients  of 
an  event  typically  perform  the  same  computations.  This  leads  to  very  different 
requirements  for  underlying  theory,  since  the  main  issue  is  how  to  add  and 
remove  replicated  servers  correctly  to  a  running  system. 

The  second  closely  related  area  of  research  is  the  area  is  formal  models  of 
concurrency.  As  we  have  said,  this  paper  draws  heavily  on  that  work,  and  es¬ 
pecially  that  of  Jones  and  St0len  [Jon83,St091].  In  our  work  we  attempt  where 
possible  to  apply  existing  research  to  this  new  domain,  and  to  understand  the 
strengths  and  limitations  of  established  techniques. 

In  the  remainder  of  this  paper  we  describe  a  formalization  of  implicit  invo¬ 
cation  systems  that  is  a  first  step  towards  this  goal.  The  next  section  introduces 
a  formal  model  for  II  systems.  Section  3  describes  the  specification  language. 
Section  4  demonstrates  how  II  systems  can  be  verified  using  rely/guarantee  rea¬ 
soning.  Section  5  concludes  and  outlines  further  work. 

2  A  formal  model  of  implicit  invocation 

We  describe  a  computational  model  for  II  systems.  A  syntax  and  an  operational 
semantics  are  given.  Two  concepts  are  crucial  to  the  model:  methods  and  events. 
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Methods  A  method  m  is  a  piece  of  (imperative)  code,  denoted  by  code[m) 
or  just  c,  also  called  program,  that  uses  local  and  global  variables.  We  assume 
there  exists  a  set  T  of  global  variables  that  can  be  read  and  written  by  the 
entire  system.  Each  method  has  its  own  set  of  local  variables.  The  local  variables 
local{iv)  of  a  method  m  can  only  be  read  or  written  by  the  code  of  m  and 
changes  to  them  are  not  visible  to  the  outside.  The  bindings  of  local  variables 

local(ni)  =  {.r'l . .r„}  are  recorded  in  the  code  c  itself  and  supersede  the 

bindings  of  global  variables  with  the  same  name.  To  this  end,  c  is  required  to  be 
of  the  form 

c  local  =  i;i, .  . . ,  XV  =  ^n]  in  (7 

for  some  }}  >  U  where  the  values  of  the  local  variables  are  given  by  the  declaration 
list  [.ri  =  T) . ~  t'„].  We  assume  that  all  of  the  Xi  through  are  distinct. 

C'  is  a  program  of  a  simple  imperative  language  augmented  with  primitives 
for  announcing  and  consuming  events  and  an  atomic  section  construct: 

C  X  expr  \  Ci\C2  \ 

if  B  then  Ci  else  C2  \  while  B  do  C  \ 
announce(e)  |  consunie(e)  |  (C) 

The  formal  semantics  of  these  statements  will  be  given  in  the  next  section.  The 
structure  of  a  method  m  is  illustrated  in  Figure  1. 


m 

local{m) 


code(rn) 


Fig.  1.  Structure  of  a  method  m 


Events  The  main  purpose  of  an  event  is  to  trigger  other  methods.  Typically, 
the  event  thus  communicates  a  certain  state  change  that  the  rest  of  the  system 
needs  to  know  about.  In  other  words,  an  event  is  announced  if  and  only  if  a 
certain  state  predicate  is  met.  Events  are  thus  a  carrier  of  semantics.  The  state 
predicate  whose  truth  is  communicated  through  an  event  e  is  called  the  semantics 
of  e,  written  sem{e). 

An  event-method-binding  EM,  or  binding  for  short,  associates  each  event  e 
with  a  set  of  methods  that  are  to  be  triggered  when  that  event  is  announced. 
Formally,  EM  is  a  possibly  empty  set  of  event-method  pairs  (e,m).  Note  that 
an  event  need  not  be  bound  to  any  methods  and  that  several  methods  can  be 
bound  to  the  same  event.  Let  EM(e)  denote  the  set  of  methods  that  e  is  bound 
to  in  EM,  that  is,  EM{e)  =  {m  \  (e,m)  G  EM}.  An  event  e  is  considered  to  be 
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external  with  respect  to  a  set  of  methods  M,  if  none  of  the  methods  in  M  issue 
e.  (Note,  however,  methods  still  can  be  bound  to  external  events.)  Events  that 
are  not  external  are  called  internal 

Definition  1.  A  system  S  —  (M,  Vy  EM,  Ex)  is  a  collection  of  methods  M  to¬ 
gether  with  a  set  of  global  variables  V ,  a  binding  EM  and  a  set  of  events  Ex 
that  is  external  to  M.  □ 

2.1  Operational  semantics 

The  essential  operational  behaviour  of  an  II  system  is  that  when  methods  exe¬ 
cute  they  may  announce  events.  When  an  event  is  announced  the  set  of  event- 
method  pairs  (as  determined  by  EM)  is  added  to  an  “active  event”  data  struc¬ 
ture  ae.  Concurrent  with  method  executions,  event-method  pairs  are  removed 
from  ae,  causing  the  invocation  of  the  associated  method.  Let  /  be  a  list  of 
{e,m)  pairs.  We  assume  that  ae  supports  two  update  operations  store{aeyl) 
and  remoi;e(ae,  (e,  m)),  two  predicates  €Tnpty{ae)  and  (e,m)  G  ae,  and  an  op¬ 
eration  #(ae,e)  that  counts  the  number  of  occurrences  of  e  in  ae,  that  is, 
#(ae,e)  =  |{(e,m)  |  (e,m)  G  ae}|.  In  this  model,  we  leave  unspecified  (i.e., 
non-deterministic)  how  precisely  the  events  are  stored  and  retrieved.  In  other 
words,  our  model  does  not  contain  any  build-in  assumptions  about,  for  exam¬ 
ple,  the  policy  that  decides  which  event-method  pair  will  be  selected  from  the 
active  event  data  structure  or  how  duplicate  occurrences  of  events  or  concur¬ 
rent  updates  should  be  handled.  In  practice,  systems  institute  specific  policies 
to  achieve  certain  kinds  of  ordering  relationships.  In  Section  3.1  we  will  see  an 
example  where  it  is  necessary  to  pick  a  particular  dispatch  policy.  However,  this 
paper  does  not  attempt  to  classify  which  policies  are  needed  by  which  applica¬ 
tions. 

To  achieve  compositionality  the  semantics  of  a  collection  of  methods  will  be 
given  subject  to  the  behaviour  of  the  environment  the  methods  are  executing 
in.  The  semantics  defines  transitions  between  configurations.  We  first  introduce 
the  components  of  a  configuration.  Methods  can  either  be  waiting  for  events 
or  executing.  To  distinguish  between  these  states  each  method  Wi  is  associated 
with  a  boolean  flag  a^.  If  a^-  =  true,  then  c^,  the  code  of  method  mj,  is  currently 
being  executed,  and  we  say  that  method  m^-  is  active,  ai  =  false  indicates  that 
code  Ci  is  currently  not  being  executed.  In  this  case,  method  m-i  is  called  idle. 

A  state  s,  is  a  mapping  from  global  variables  to  values,  s  :  V  ^  Val  Whenever 
(e,m)  G  ae  then  event  e  is  currently  active  and  still  needs  to  be  delivered  to 
method  m. 

Definition  2.  Let  Ci  be  programs,  af  be  boolean  flags,  s  a  state,  and  ae  the 
active  events  data  structure.  A  configuration  is  a  3-tuple 

where  ((cj,  =  ((ci,  ai), . . . ,  (cn, ,  a„)).  If  the  precise  number  of  methods 

is  irrelevant,  we  will  abbreviate  this  by  {{ci,ai))i. 
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A  transition  is  of  the  form  (((c/,  5*,  a*))*,  5,  ae)  (((c-,  5-,  a-))*,  5',  ae') 

where  the  label  I  is  one  of  {env^  pro] .  If  /  —  pro  then  we  have  a  program  transi¬ 
tion.  Environment  transitions  have  /  =  env.  Intuitively,  environment  transitions 
model  transitions  made  by  other  methods  in  the  system.  □ 

Method  semantics  Before  the  operational  semantics  of  the  overall  system  can 
be  defined,  we  need  to  give  a  semantics  for  the  code  of  a  method.  This  semantics 
is  a  family  of  local  transition  relations  that  is  parameterized  with  the 

current  binding  EM,  and  the  method  m  which  is  currently  executing.  These 
local  transition  relations  link  local  configurations  of  the  form  s,aey.  A  local 
transition 

■<c,s,ae) - >(Bjv/,m)  -:c',s',aeV 

means  that  code  c  transformed  state  s  and  the  active  events  data  structure  ae 
to  s'  and  ae'  respectively  assuming  that  c  is  executed  under  the  binding  EM^ 
and  that  c  is  the  code  of  method  m.  The  remainder  of  the  code  is  c'.  A  local 
transition 

-<c,s^ae)>-  <s\ae'>- 

additionally  expresses  that  c  terminates  in  one  step. 

The  imperative  constructs  have  the  standard  semantics.  Assignments,  for 
example,  are  defined  as  follows: 


- — - ^ -  if  e  evaluates  to  n  in  s 

e,s,ae)>-  -^(EM,m)  “  n\,aey 

The  atomic  section  construct  hides  intermediate  states: 

<C,s,ae>- 

x(C),5,ae>-  ^[EM,m)  -<s\ae'>- 

where  ^'l^EM,m)  denotes  the  reflexive  and  transitive  closure  of  ^{EM^m)- 
The  event  primitives  announce  and  consume  behave  as  follows: 


-(announce(e),5,ae;^  '^{EM,m)  store{ae,[{e,mi), . . .  ,{e,rnn)])>- 

where  EM{e)  =  That  is,  announce(e)  causes  (e,m')  to  be  an¬ 

nounced  only  if  e  is  bound  to  m'  in  the  current  binding  EM.  Note  that  if  an 
announced  event  has  no  methods  bound  to  it  by  EM,  no  pairs  are  added  to  the 
active  event  data  structure  —  that  is,  ae  is  unchanged. 

Once  a  consume(e)  is  executed  by  method  m,  the  event  e  is  considered  de¬ 
livered  to  m  and  the  pair  (e,  m)  is  removed  from  the  active  events  data  structure. 


^  consume(e),  s,  ae  -<s,remove{ae,(e,m))y 
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We  want  a  local  variable  declaration  to  hide  the  changes  of  the  declared  vari¬ 
ables.  We  adopt  the  standard  operational  treatment  of  local  variables.  If,  from 
a  state  in  which  the  local  variables  carry  their  local  values,  C  has  a  transition 
to  ^  Cb  .‘'b  (if^  y,  then  local  lb  in  C,s,ae>-  has  a  transition  that  leaves  the 
values  of  the  local  variables  unchanged  and  stores  the  new  values  of  the  local 
variables  in  the  updated  declaration  list  dl' . 

[.s|.ri  ~  Vi\..,\xn-  Vn]^aey  (C^g^ae^) 

•floral  dl  in  C\s,ae>-  '^(EM,m)  ^ local  d^  in  C' ,s\a€  >- 

where  dl  =  [.ri  =  vy - ,Xn  —  Vn]  and  dl'  =  [.^i  =  s' (xi), . . . ,  Xn  =  -5'(a:n)]  and 

s"  —  [.s'|.rj  =  .s(.r}  )| . . .  =  ^(x’n)].  Termination  of  the  body  of  a  declaration 

induces  t('rmination  of  the  declaration. 

^(\  [.s|.ri  =  I’ll  .  ..\xn  =  Vn]:Oey-  '^{EM,m)  -<  s' ,  ae' y 
*-<local  dl  in  C,  s,  aey 

where  dl  =  [.ri  =  ci . Xn  =  and  s"  =  =  s(a?i)|..  .\xn  =  ^(^n)]- 

System  semantics  We  are  now  ready  to  define  the  global  transition  relation 
that  describes  the  behaviour  of  the  entire  system. 

Definition  3.  For  each  binding  EMthe  transition  relation  — ^em  is  the  smallest 
relation  satisfying 

-  environment  transitions: 


{{(ci,ai))i,s,ae)  ^em  (((c,,  a,)),,  s',  ae') 

for  all  Ci,  Qi,  s,ae,s' ,  ae'  and 
—  program  transitions: 

{{{cij  Oi), . .  • ,  (Ci,ai), (Cn,  a„)),  s,  ae)  ^em 

(((ci,o.i), . . (c',  a'), . . . ,  (c„,a„)),  s',ae') 

whenever 

1.  a-i  =  true  and  -<Ci,  s,  aey  -<  c'- ,  s' ,  ae' )>-  and  aj-  ~  a^  ,  or 

2.  ai  =  true  and  -<Ci,s,  ae  '^{EM,mr)  -<  s' ,  ae'  >-  and  c'^  =  code{mi)  and 
a  ■  false,  or 

3.  (e,  m-i)  G  o.e  and  ai  =  false  and  a'  =  true  and  c'  —  c  and  ae'  =  ae,  □ 

The  intuition  behind  the  above  definition  is  the  following:  The  environment  has 
access  to  the  global  state  and  the  active  events  data  structure  and  can  change 
these  arbitrarily  in  an  environment  transition.  A  program  transition  can  arise  in 
three  different  situations: 

1.  If  a  method  is  active  and  its  code  is  not  yet  terminated,  then  it  continues  to 
be  active  and  execute  its  code. 
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2.  If  a  method  is  active  and  its  code  terminates,  then  it  is  set  to  idle,  and  the 
code  is  restored. 

3.  If  event  e  is  active  and  bound  to  method  mi  that  is  not  currently  active, 
then  rui  can  be  activated. 

Note  that  an  event  cannot  trigger  a  method  that  is  already  active.  In  other 
words,  at  most  one  “incarnation”  of  each  method  is  active  at  any  time.  Once 
a  method  has  been  activated,  its  code  will  be  fully  executed  before  it  gets  de¬ 
activated.  Also  note  that  this  formulation  can  readily  be  extended  to  handle, 
for  instance,  changes  to  the  EM  binding  at  runtime,  or  the  use  of  more  specific 
method  activation  strategies. 

When  reasoning  about  an  II  system  it  is  typically  the  case  that  one  wants 
to  assert  the  establishment  of  some  predicate  once  the  system  has  reached  a 
quiescent  state.  To  facilitate  that  we  identify  a  disabled  configuration  as  one 
that  can  make  no  transitions. 

Definition  4.  A  configuration  (((cf,  Si,ai))i,  s,  ae)  is  disabled  under  EM  if  there 
are  no  cj-,  a^,  s'  and  ae'  such  that 

{{{ci,si,ai))i,s,ae)  ^em  (((c-, s', a-)),-,  s',  ae'). 

Definition  5.  A  computation  under  some  binding  EM  is  a  possibly  infinite  se¬ 
quence  of  program  and  environment  transitions 

(((ci,,  ^1,,  si,  aei)  -^em  •  •  •  ^  (((cj, ,  aej)  -^em  •  •  • 

such  that  the  final  configuration  is  disabled  under  EM  if  the  sequence  is  finite. 
A  finite  computation  is  also  said  to  be  terminating.  □ 

Given  a  computation  cr,  then  C(cr),  5(cr),  AE(a)  and  L[a)  are  the  obvious 
projection  functions  to  sequences  of  programs,  states,  active  events  and  transi¬ 
tion  labels.  (r[i],  C(<7,  f),  A(cr,  i),  5(cr,  f),  AE{a,  i)  and  Z/((T,  i)  denote,  respectively, 
the  i^^  configuration  ,  s,ae),  the  i^^  vector  of  programs  {ci)i,  the 

i^^  vector  of  flags  {ai)i,  the  i^^  state  the  i^^  active  events  data  structure  ae^-, 
and  the  i^^  label  of  a.  Let  SxAE  be  the  product  of  the  two  projection  functions 
5  and  AE,  that  is,  SxAE  {a,  i)  —  AE{a,i)). 

Given  a  system  S,  cr  is  a.  computation  of  <5  if  it  starts  out  with  a  set  of 
inactive  methods. 

Definition  6.  Given  a  system  S  =  (M,  V,  EM,  Ex)  with  M  =  {mi, . . . ,  mn}, 
the  set  of  all  computations  of  S,  comp{S),  is  given  by  all  computations  a  under 
with  C{(T,  1)  =  {code(mi))f_^  and  A(<t,  1)  =  □ 

3  Specification  language 

Rely /guarantee  reasoning  [Jon83,St091]  has  successfully  been  applied  to  concur¬ 
rent  systems.  We  now  show  this  approach  can  be  extended  to  our  computational 
model  of  II  systems. 
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Predicates  States  are  described  by  state  predicates.  As  usual,  these  are  formu¬ 
las  consisting  of  constants,  variables,  function  and  predicate  symbols  and  the 
standard  boolean  connectives.  Unprimed  variables  will  be  used  to  refer  to  an 
ear/zer  system  state.  Note  that  this  is  not  necessarily  the  previous  state.  Thus, 
for  each  variable  x,  there  is  a  primed  variable  x\  Primed  variables  cannot  ap¬ 
pear  in  programs.  Let  A  be  a  state  predicate.  We  write  (^i,  s'2)  [=  A  if  A  is  true 
when  each  unprimed  variable  in  A  is  assigned  the  value  Si  (x)  and  each  primed 
variable  x'  in  A  is  assigned  the  value  S2(^0-  ^  state  predicate  A  can  thus  be 
interpreted  as  the  set  of  pairs  of  states  (51,52)  such  that  (51,52)  |=  A.  In  this 
case,  A  is  called  a  binary  state  predicate.  If,  however,  A  does  not  contain  any 
primed  variables,  then  A  may  also  be  thought  of  as  the  set  of  states  5  such  that 
5  1=  A.  A  is  called  a  unary  state  predicate  in  this  case. 

In  certain  situations  we  also  want  to  express  how  the  active  events  data 
structure  will  be  changed  in  the  course  of  a  transition.  To  this  end  we  introduce 
event  predicates.  The  variable  ae  is  reserved  to  denote  the  active  events  data 
structure.  Given  an  event  e,  an  event  predicate  is  a  boolean  combination  of  the 
atomic  predicates  active{e),  e++  and  e — .  Let  ae  and  ae'  be  two  active  events 
data  structures.  We  say  acttve(e)  is  true  in  (ae,  ae')  if  there  is  a  method  m  such 
that  (e,m)  G  ae',  that  is,  (ae,ae')  \=  active{e)  iff  (e,  m)  G  ae'  for  some  m. 
e++  expresses  that  e  has  just  been  announced,  e —  says  that  e  has  just  been 
consumed.  e++  (or  e — )  is  true  in  (ae,ae')  if  the  number  of  occurrences  of  e 
in  ae'  is  one  greater  (or  smaller)  than  the  number  of  occurrences  of  e  in  ae. 
Formally,  (ae,ae')  |=  e++  iff  #(ae,e)  =  9y:(ae',e)  +  1  and  (ae,ae')  |=  e —  iff 
#(ae,e)  =  #(ae',e)  —  1.  A  state-event  predicate  is  the  boolean  combination  of 
state  and  event  predicates  and  is  thus  interpreted  over  4-tuples  ((5,  ae),  (5',  ae')) 
in  the  obvious  fashion. 


Specifications  A  specification  is  of  the  form  (p  =  (P, /?.,  G,Q),  where  the 
pre-condition  P  is  a  unary  event-state  predicate,  and  the  rely- condition  P,  the 
guarantee- condition  G,  the  input /output-condition  Q  are  binary  event-state  pred¬ 
icates. 

Let  len{cr)  be  the  number  of  configurations  in  cr.  Given  a  set  of  variables 
X  and  two  states  5i,  52,  then  5i  =a'  ^2  denotes  that  for  all  variables  x  G  X, 
Si(x)  =  52(3?)  while  Si  ^2  denotes  that  there  exists  a  variable  a?  G  A,  such 
that  5i  (a?)  ^  52 (ir). 

Definition  7.  Let  V  be  the  set  of  global  program  variables.  Given  a  binding 
EM,  a  pre-condition  P,  a  rely-condition  P,  then  env(V,  P,  R)  denotes  the  set  of 
all  computations  a  under  EM,  such  that 

-  SxAE{(t,  1)  1=  P, 

-  for  all  1  <  z  <  l€n{cr),  whenever  L{a,i)  =  env  and  S{cr,i)  /y  S{(T,i  -f-  1), 

then  {SxAE{a,  i),  SxAE{a,  z-f  1))  \=  R.  That  is,  all  environment  transitions 
that  change  the  value  of  at  least  one  variable  satisfy  the  rely  P.  □ 
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Definition  8.  Let  V  be  the  set  of  global  program  variables.  Given  a  binding 
EM,  a  guarantee-condition  G,  a  input/output-condition  Q,  then  prog{V,G,Q) 
denotes  the  set  of  all  computations  <t  under  EM,  such  that 

-  cr  is  finite, 

-  for  all  1  <  z  <  len{a),  whenever  L{a,i)  =  pro  and  S((T,i)  S[(t,i  +  1), 
then  [SxAE{(t,  i),  SxAE[(t,  z  +  1))  \=  G.  That  is,  all  program  transitions  that 
change  the  value  of  at  least  one  variable  satisfy  the  guarantee  G. 

-  {SxAE{a,  1),  SxAE{a,  len{a)))  ^  g.  □ 


Judgements  A  judgement  is  a  pair  consisting  of  a  system  S  =  [M,  V,  EM,  Ex), 
and  a  specification  =  (P,R,G,Q),  written  5  |=  A  judgement  is  true,  if 
all  computations  cr  of  M  under  EM  are  such  that  whenever  cr  terminates  and 
satisfies  the  relies  (on  initial  state  and  environment  transitions),  then  it  will  also 
satisfy  the  guarantees  (on  the  program  transitions  and  the  final  state). 

Definition  9.  Let  S  =  {M,  V,  EM,  Ex)  be  a  system.  The  judgement 

5  ^  {P,R,G,Q) 

is  true  iff 

com,p{S)  n  env{V,  P,  R)  C  prog(V,  G,  Q). 

□ 


We  now  define  executions.  These  are  finite  computations  that  start  and  end 
with  an  empty  active  events  data  structure  and  restrict  top-level  environment 
interference  to  the  announcement  of  external  events  while  the  state  is  left  un¬ 
changed. 

Definition  10.  Let  S  —  (M,  V,  EM,  Ex)  be  a  system.  The  set  of  executions  of 
S,  exec[S),  is  given  by 

€xec{S)  —  comp[S)  Pi  env{V,  empty{ae),  Rex)  H  prog[V,  true,  true) 
where  Rex  is 

i/\xev^'  ~ 

(ae'  -  store{ae,[{ei,mi),.,.,{en,rnn)]))A 
^  ^  Ex  A  {ci ,  rrii)  G  EM) 

and  thus  restricts  the  top-level  environment  to  the  announcement  of  external 
events.  For  state-event  predicates  P  and  Q,  a  partial  correctness  triple 

is  true  iff  every  execution  of  S  that  starts  in  a  state  satisfying  P  terminates  in 
a  state  such  that  Q  holds.  □ 

When  considering  executions  the  system  is  thus  regarded  not  as  a  closed  sys¬ 
tem  but  one  that  is  still  subject  to  interference  by  the  top-level  environment. 
However,  this  interference  is  limited  to  the  announcement  of  external  events. 
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3,1  Example:  sets  and  counters 


A  common  use  of  II  systems  is  to  provide  loose  coupling  between  parts  of  a 
system  that  are  individually  responsible  for  updating  separate  portions  of  the 
state.  The  EM  binding  is  used  to  provide  establish  relationships  between  the 
different  parts  of  the  system  state:  specifically,  when  one  part  of  the  system 
changes  its  part  of  the  state,  events  trigger  corresponding  updates  to  other  parts 
of  the  state. 

As  a  simple  example,  consider  a  system  in  which  the  state  consists  of  a  set 
and  a  counter.  The  set  has  methods  to  insert  and  delete  elements.  The  counter 
has  increment  and  decrement  methods.  The  E'Af  binding  is  then  used  to  establish 
a  system  “invariant'’  that  the  value  of  the  counter  be  the  size  of  the  set.  Formally, 
consider  a  system  S  with  methods 

M  =  {tnsert(x),  increment^  d€lete[x),  decrement} , 

global  variables  V  =  {C,  5},  external  events  Ex  =  {ins{n) ,  del{n)  \  n  G  N], 
internal  events  {mcr,  deer},  and  binding  EM  with 


event 

method 

ins[n) 

tnsert{x) 

del{n) 

delete(x) 

tner 

increment 

deer 

decrement 

The  idea  is  that  an  element  n  can  be  inserted  into  or  deleted  from  the  set 
S  using  the  method  insert{x)  or  delete{x).  Analogously,  the  counter  C  can  be 
incremented  or  decremented  using  increment  or  decrement.  In  this  case  EM 
provides  the  necessary  binding  between  events  announced  by  the  methods  that 
change  the  state  of  the  set,  so  that  the  state  of  the  counter  can  be  updated.  The 
methods  have  the  following  structure. 


m  : 

insert{x) 

d€lete{x) 

local{m)  : 

0 

0 

code{m)  : 

local  0  in 

local  P  in 

consume(  ins(x) ) ; 

consume(  del  {x))] 

if  X  ^  S  then 

if  X  E  S  then 

(5  :=SU{x}; 

(5  :=  5\{*}; 

announce(  incr)) 

announce(decr)) 

In  the  methods  above  x  is  used  as  a  formal  parameter  that  is  instantiated 
upon  method  invocation. 
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m  : 

increment 

decrement 

local[m)  : 

0 

0 

code{m)  : 

local  |]  in 

local  U  in 

{C 

(C 

consume(incr)) 

consunie(dec7’)) 

Given  the  external  event  ins{n),  the  formal  parameter  x  of  method  insert[x) 
is  replaced  by  n  and  the  method  is  invoked.  Similarly  for  external  events  del{n). 
If  necessary,  the  set  5  is  updated  by  inserting  or  deleting  the  element  n  and 
the  corresponding  event  is  announced.  This  in  turn  triggers  either  increment  or 
decrement. 

The  above  methods  communicate  by  exchanging  the  events  incr  and  deer. 
These  events  have  the  following  semantics. 


event  e 

sem[e) 

incr 

3x.x  ^  S  /\  =  Syj  {j?} 

deer 

3x.x  E  S  A  S'  =  5\{a:} 

Given  a  set  of  events  E,  the  characteristic  formula  of  E  expresses  that  all 
events  in  E  get  announced  if  and  only  if  their  semantics  is  met.  Formally,  cfE  is 
f\eeE  (e++  sem(e)).  Making  c/e  part  of  the  guarantee  condition,  thus  allows 
us  to  show  that  a  given  method  respects  the  semantics  of  its  events. 

When  run  in  an  initial  state  in  which  x  ^  S,  insert{x)  announces  the  event 
zner  precisely  when  its  semantics  is  met.  Similarly  for  delete{x)  and  initial  states 
in  which  x  ^  S.li  these  preconditions  are  not  met,  both  methods  will  not  cause 
any  state  change  (the  next  state  relation  is  restricted  to  stuttering  through  the 
guarantee  false).  Unrestricted  environment  interference  prevents  us  from  being 
able  to  make  any  non-trivial  assertions  about  the  final  state.  Formally, 

i^inserti^x) ^  U,  EM^  Ex)  (^  ^  S*,  true^  ^f\incr,d€cr}  ^  true) 

{insert{xy,  V,  EM,  Ex)  [=  (x  E  S,  true,  false,  true) 

{delete{x),  U,  EM,  Ex)  \=^  {x  e  S,  true,  c/{,„cr,decr},  true) 

{delete(x),  V,  EM,  Ex)  \=  [x  ^  S,  true,  false,  true). 

We  assume  that  events  are  commutative,  that  is,  the  order  in  which  they  are 
announced  is  irrelevant.  In  this  case  an  implementation  of  ae  as  a  multiset  would 
therefore  be  correct. 

Suppose  we  wanted  to  extend  our  system  by  the  external  event  init,  the 
internal  event  res,  the  methods  initialize  and  reset  and  the  bindings 


event 

method 

init 

initialize 

res 

reset 
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where 


m  : 

local{m)  : 
coJe(m)  : 


initialize 

0 


local  []  in 

consume{init)] 

{S  0; 

announce(re5)) 


The  external  event  causes  method  initialize  to  be  invoked,  which  empties 
the  set  and  announces  the  res  event.  This  in  turn  triggers  the  reset  method 
which  sets  the  counter  to  0.  Note  that  in  this  extended  system  events  are  not 
commutative  anymore.  We  need  to  keep  track  of  the  order  in  which  events  are 
announced  and  thus  require  a  more  refined  computational  model.  More  precisely, 
the  active  events  data  structure  ae  must  thus  be  kept  in  a  queue  rather  than  a 
multiset. 


4  Formal  reasoning 

Assume  that  we  want  to  reason  about  the  system  S  =  (M,  V,  EM,  Ex)  and  show 
that  it  satisfies  some  partial  correctness  triple  {P5}  5  {Q^}.  This  section  shows 
how  this  can  be  accomplished. 

1.  We  start  with  some  local  reasoning  on  the  method  level. 

(a)  First,  we  choose  appropriate  predicates  P,  R,  and  Q  describing  the  ini¬ 
tial  state,  the  relies  on  the  top-level  environment,  and  the  final  state 
respectively. 

(b)  For  each  method  m  G  M  and  the  corresponding  “rest  of  the  system” 
M\{m}  we  identify  guarantees  Gm  and  GM\{m]  such  that  , 

i.  whenever  m  is  executed  from  an  initial  state  satisfying  P  and  in 
an  environment  satisfying  R  V  GM\{m]  and  terminates,  then  m  will 
change  the  state  according  to  Gm  and  the  final  state  will  be  such 
that  Q  holds.  Formally, 

{m,V,EM,Ex)  1=  iP,R\/  GM\{m},Gm,Q) 
for  all  m  G  M ,  and 

ii.  whenever  the  rest  of  the  system,  is  run  from  an  initial  state 

satisfying  P  and  in  an  environment  satisfying  RwGm  and  terminates, 
then  M\{m}  will  change  the  state  according  to  GM\{m}  and  the  final 
state  will  be  such  that  Q  holds.  Formally, 

V,  EM,  Ex)  |=  (P,  i?  V  Gm,GM\{m},Q) 

for  all  m  G  M. 
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Intuitively,  the  above  shows  that  both  the  method  m  and  the  rest  of  the 
system  M\{m}  stick  to  their  guarantees  if  the  other  one  does. 

(c)  Now  it  is  safe  to  conclude  that  whenever  the  entire  system  is  executed 
in  an  initial  state  satisfying  P  and  in  an  environment  satisfying  R  and 
terminates,  then  it  will  change  the  state  according  to  VmeM  and  the 
final  state  will  be  such  that  Q  is  met.  That  is, 

(M,  y,  EM,  Ex)  ^  (P,  R,  ,  Q). 

The  soundness  of  this  step  is  implied  by  the  rely /guarantee  reasoning 
method  put  forward  by  Jones  and  others  [Jon83,St091]. 

2.  Now  we  weaken  the  above  judgement.  By  definition,  every  execution  starts  in 
a  state  with  empty{ae)  and  the  interference  allowed  by  the  top-level  environ¬ 
ment  is  described  by  Rex-  Moreover,  we  are  only  interested  in  initial  states 
satisfying  Ps .  Thus,  we  need  to  show^  Ps  A  empty{ae)  P  and  Rex  ^  R- 
In  this  case,  we  get 

{M,  V,  EM,  Ex)  1=  {Ps  A  ae  =  0,  Rbx,  true,  Q). 

3.  Due  to  the  semantics  of  announce(e),  ae  cannot  contain  events  that  do  not 
trigger  anything.  Thus,  every  disabled  configuration  must  have  €mpty[ae). 
To  obtain  the  desired  partial  correctness  property,  we  therefore  need  to  show 
Q  A  empty{a€)  ^  In  this  case,  it  is  sound  to  conclude  that  the  partial 
correctness  property  holds 


{Ps]S{Qs]. 

Following  [Jon83,St091]  a  more  general  formulation  step  1  would  be  possible. 
However,  the  present  treatment  is  sufficient  for  our  purposes. 


4.1  Example:  sets  and  counters 

Let  S  be  the  system  introduced  in  Section  3.1.  By  binding  the  mcr  and  the  deer 
events  to  increment  and  decrement  respectively,  we  hope  to  have  established  a 
link  between  the  size  of  the  set  S  and  the  value  of  the  counter  (7.  More  precisely, 
we  want  the  triple 

{|5|:^C'}5{|5|  =  C'} 

to  hold. 

1.  Let  Ii  be  given  by 


Ii  =  (|S|  =  C  +  #incr  —  #decr) 

where  #e  abbreviates  the  number  of  occurrences  of  e  in  ae,  that  is,  #(ae,  e). 
To  prove  the  partial  correctness  property  above  we  adopt  the  outlined  strat¬ 
egy  in  a  somewhat  degenerate  but  sufficient  fashion.  We  show  that  R  is 
an  invariant  for  each  of  the  methods  and  thus  also  for  the  entire  system. 
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More  precisely,  with  respect  to  the  above  strategy  we  let  P  —  R  =  Gm  = 
GM\{m]  —  Q  —  h  for  all  m.  E  M ,  We  can  show  that  all  methods  preserve 

/i. 


for  all  m  G  {ins€rt[x) ,  delete[x),  increment^  decrement}. 

This  part  of  the  verification  reveals  an  important  point.  R  expresses  a 
relationship  between  the  state  variables  and  the  active  events  data  structure. 

For  this  invariant  to  be  preserved  by  every  transition,  it  is  necessary  that 
every  method  announces  changes  to  the  state  variables  that  destroy  that 
relationship  by  simultaneously  announcing  the  corresponding  event  using 
the  atomic  section  construct.  If,  for  instance,  a  method  first  updates  the 
state  variables  and  then  announces  the  event  at  some  later  stage,  it  is  likely 
to  be  impossible  to  establish  any  non-trivial  relationship  between  the  state 
variables  and  the  pending  events  for  that  method.  We  regard  the  need  for  an 
atomic  region  construct  as  a  limitation  of  our  framework  that  compromises 
practicality.  Section  5  contains  a  more  detailed  discussion  of  this  issue. 

Next,  it  is  easy  to  see  that  for  each  m  the  rest  of  the  system  M\{?’n} 
also  preserves  the  invariant. 

(M\{m}^']EM,Ex)  h-  (hJiJiJi) 

for  all  771  6  {tnsert{x),  delet€{x),  increment,  decrement] .  Thus,  R  is  an  in¬ 
variant  for  all  of  S. 

2.  We  weaken  the  specification  (/i,  /i ,  /i,  /i)  to  {C  —  \S\A€mpty{ae),  Rex,  R). 
Note  that  C  =  |5|  A  empty{ae)  ^  R  and  Rex  ^  R>  Thus, 

5  1=  (C  =  l^l  A  empty[ae),  Rex,  true,  R). 


3.  We  show 

{C-|5|}5{C'=|5|} 

by  arguing  that  R  A  empty[ae)  implies  C  —  |5|. 

Note  that  the  above  reasoning  could  easily  be  extended  to  handle  the  example 
system  augmented  with  the  methods  initialize  and  reset  under  the  appropriate 
binding. 


4.2  Example:  a  filesystem 

We  now  consider  an  example  inspired  by  the  common  application  of  implicit 
invocation  to  software  development  environments,  such  as  Field  [Rei90]. 

Previously,  a  state  was  a  mapping  from  variables  to  values.  We  now  consider 
a  slightly  different  scenario,  in  which  the  state  is  given  by  the  contents  and  the 
attributes  of  a  file  system  E.  Suppose  F  is  a  set  of  source  files.  We  assume  that 


16 


the  files  in  F  correspond  to  an  executable  file  target  and  that  tmLlie[F,  target) 
creates  a  new  executable  with  respect  to  the  current  contents  of  F. 

In  the  following,  /  will  range  over  files  in  F.  The  system  F  contains  the 
methods  M  =  {edit(f),  compile],  the  internal  event  modified,  the  external  events 
update{f),  and  the  binding  EM  with 


The  semantics  of  the  modified  event  is 

sem{modifi€d)  =  ~>fresh{target,  F) 

where  fresh{f,  F)  denotes  that  the  last  modification  date  of  /  is  more  recent 
than  that  of  all  files  in  F,  that  is,  for  all  f  E  F, 

dateJasLmodified{f)  >  dateJasLmodified(f). 

We  assume  that  the  methods  are  of  the  following  form: 

771  : 

local{m)  : 
code[m)  : 


An  external  updat€{f)  event  causes  the  file  /  to  be  edited.  The  edit{f)  method 
copies  the  contents  of  /  into  a  local  buffer  buf  and  if,  at  the  end  of  the  edit 
session,  the  buffer  differs  from  the  contents  of  /,  then  /  is  updated  with  buf. 
If  /  also  is  a  source  file  relevant  to  target  the  modified  event  is  announced.  The 
modified  event  triggers  the  compile  method  which  updates  the  executable.  Note 
that  the  update[f)  and  the  modified  event  are  not  commutative,  that  is,  the  order 
in  which  events  are  announced  does  matter.  Again,  this  means  that  ae  must  be 
kept  as  a  queue  rather  than  a  multiset. 

We  would  like  to  show  that 

{fresh{target,  F)}  F  {fresh{target,  F)} . 

To  this  end,  we  again  first  establish  an  invariant.  However,  in  contrast  to  the 
previous  example,  we  make  use  of  the  semantics  of  the  modified  event  to  prove 
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the  invariant.  Let 


I2  =  fresh{target,  F)  V  sem (modified) 

1 2  =  fresh(target,  F)  V  active(modified)  V 

(F'  =  F  A  ~~»(modifi€d‘\-+)  A  --iim.odtfied — )). 

In  is  a  tautology  and  thus  trivially  an  invariant.  We  can  show  that  whenever 
the  environment  changes  the  state  according  to  then  edit{f)  will  announce 
modified  if  and  only  if  its  semantics  is  met.  Similarly  for  compile. 

(edtt(f),  I/,  EM,  Ex)  |=  (true,  /^,  cfmod^  I2) 

(compile,  V,  EM,  Ex)  1=  (true,  I2,  cfm.od,  I2) 

where  cf^od  ^  modified++  sem(modtfied) .  Using  the  tautology  I2  it  is  easy  to 
see  that  cfmod  implies  Consequently,  the  relies  and  guarantees  fit  together, 
and  we  can  conclude 


F  [=  (time,  I2,  cfjYiod’i  -^2)' 

Since  Rex  implies  this  can  be  weakened  to 

F  1=  (empty(ae)  A  fresh(target,  F),Rex,  true,  I 2) 
which  then  implies  the  desired  result 

{fresh(target,  F)]  F  {fresh(target,  F)} . 

5  Conclusion  and  further  work 

We  have  presented  a  formal  model  of  II.  Using  this  model  as  a  guideline,  we 
developed  a  framework  that  supports  formal  reasoning  about  II  systems.  This 
framework  was  obtained  as  an  extension  of  Jones’  rely /guarantee  reasoning,  and 
thus  naturally  inherits  many  of  its  benefits  and  deficiencies  like,  for  instance,  the 
reconciliation  of  concurrency  and  compositionality  and  the  lack  of  support  for 
liveness  properties.  Several  examples  illustrated  the  use  and  applicability  of  the 
proposed  framework.  A  potential  abstraction  mechanism  is  offered  through  the 
event  semantics. 

The  problem  of  atomicity  is  inherent  to  concurrent  systems  with  shared  re¬ 
sources.  It  resurfaces  in  this  work  with  the  following  interesting  consequences. 
To  allow  for  fine-grained  parallelism  we  also  chose  a  fine-grained  operational  se¬ 
mantics.  On  the  specification  level,  however,  we  would  like  to  be  more  abstract 
and  not  always  be  forced  to  reason  about  every  transition.  Unfortunately,  the 
kind  of  rely /guarantee  reasoning  adopted  here  requires  us  to  do  exactly  that:  An 
assertion  is  only  an  invariant  if  it  is  preserved  by  every  transition.  As  we  have 
seen,  invariants  are  crucial  for  the  verification.  To  be  able  to  prove  non-trivial 
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invariants,  we  thus  had  to  enforce  certain  atomicity  constraints  by  means  of  an 
atomic  region  construct. 

This  is  undesirable  for  three  reasons:  First,  it  conflicts  with  our  ideal  of  fine 
grained  parallelism.  Second,  it  compromises  the  practicality  of  the  framework, 
since  sometimes  II  systems  are  implemented  without  such  a  construct.  Third, 
and  most  importantly,  it  seems  to  be,  in  some  sense,  an  unnecessary  restric¬ 
tion.  Consider  the  set /counter  example.  Suppose  we  removed  all  critical  region 
constructs.  The  invariant  would  obviously  fail,  whereas  the  partial  correctness 
property  would  continue  to  hold.  What  is  essential  here  is  that  every  set  update 
is  eventually  followed  by  the  announcement  of  the  appropriate  event.  The  simul¬ 
taneity  in  our  framework  enforced  by  the  need  for  an  invariant  is  just  a  special 
case  of  this.  This  reveals  a  fundamental  mismatch  between  judgements  that  are 
true  on  the  one  hand  and  judgements  that  can  be  proven  in  our  framework  on 
the  other  hand. 

Another  artifact  of  our  need  for  low  level  invariants  is  the  explicit  consume(e) 
statement.  On  the  one  hand,  it  allows  us  to  pinpoint  changes  to  the  active  events 
data  structure  to  transitions  that  also  update  the  state  in  a  specific  way.  On  the 
other  hand,  it  compromises  practicality  and  maintainability.  II  systems  in  gen¬ 
eral  do  not  have  an  explicit  consume(e)  statement.  Instead,  system  runtime 
mechanisms  invoke  the  method  bound  to  an  event,  automatically  removing  that 
event  from  active  event  set.  Moreover,  the  explicit  consumption  of  events  intro¬ 
duces  an  unnecessary  dependency  between  the  event-method  binding  EM  and 
the  code  of  a  method.  In  particular,  changes  to  EM  must  be  reflected  by  changes 
to  the  consume  statements. 


Further  work  The  most  important  focus  of  further  work  will  be  the  devel¬ 
opment  of  a  verification  framework  that  does  not  impose  the  restrictions  men¬ 
tioned  above.  Such  a  framework  would  allow,  for  example,  the  proof  of  the  par¬ 
tial  correctness  triple  of  the  counter  example  even  when  the  insert{x)  method 
chooses  to  announce  the  incr  after  the  actual  update  of  the  set.  The  framework 
should  also  not  depend  on  the  explicit  consumption  of  events.  A  formulation  of 
rely /guarantee  reasoning  in  which  relies  and  guarantees  can  be  given  in  terms 
of  temporal  logic  formulas  seems  promising  in  this  respect. 

The  event  semantics  plays  only  a  peripheral  role  in  this  paper.  However,  we 
envision  it  as  a  powerful  abstraction  mechanism  that  forms  the  basis  of  a  two 
stage  process:  First,  it  shown  that  events  are  announced  precisely  when  they  are 
supposed  to.  In  other  words,  using  local  reasoning  similar  to  the  one  described 
in  this  paper,  we  prove  that  all  methods  respect  the  event  semantics.  Second, 
this  event  semantics  is  then  used  to  do  global  reasoning,  that  is,  the  behaviour 
of  the  overall  system  is  reasoned  about  purely  in  terms  of  the  events  and  their 
semantics.  To  structure  the  reasoning,  it  might  then  be  helpful  to  organize  the 
dependencies  between  events  by  means  of  a  graph  or  even  a  Petri  net. 
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